This invention relates to computer systems, and, more particularly, to the synchronization of data between a host computer and a handheld client computer.
As a result of increases in computing power and available on-board memory, handheld or palmtop computers have the potential to replace laptop and desktop computers in many situations. Most uses of handheld computers to date have been oriented toward stand-alone applications such as an individual keeping a calendar and phone list, note taking, and the like. However, handheld computers are being increasingly used in corporate and public data networks (e.g., the Internet). In such systems, a host computer serves as the central data-storage site and manager of a number of handheld client computers. The client computers communicate with the host computer, but not with each other.
For example, each salesperson of a company may keep a local copy of a data base including records of customer information, inventory, catalogs, up-to-date pricing information, and other relevant data. The local database is stored on the salesperson""s handheld client computer. A master corporate database containing a similar record set is stored in the host computer. The updating of the handheld client databases is accomplished using the handheld client computer communicating with the host central computer via a data channel such as a direct hookup, a telephone line, a wireless link, or the Internet. At the same time, the handheld database sales records may be automatically transferred to the host computer from the client computers, thus allowing the central sales records to be updated.
One of the important issues in the development of such host/client systems is the synchronization of the data records of the host computer and the individual handheld client computers. Each time a data record within either the host computer or one of the client computers changes, there is a question of whether the corresponding records in the other computers of the system should be altered responsively, or xe2x80x9csynchronizedxe2x80x9d to it. In the salesperson example, a sale by one salesperson decreases the available inventory of that item, or manufacturing operations may increase the available inventory of that item. It is desirable that the host computer and, through the host computer, every other salesperson""s client computer be made aware of the up-to-date inventory status by synchronization of the applicable inventory records.
Record synchronization is a complex process because the communication between the host computer and each client computer occurs only when the data links are made on an occasional basis. Synchronization is also complex because it entails more than just blindly matching data bases. For example, if an error is made in a data entry on one of the client computers, during synchronization the host computer may seek to discover the error and not synchronize the records on the other client computers if an error is suspected. Record synchronization techniques are available to achieve synchronization of the records of two data bases that may be tailored to account for such issues.
The present inventors have observed that the record synchronization process may require long connection times between the host computer and each individual client computer, particularly when the data channel is a xe2x80x9chigh-latencyxe2x80x9d data channel that has inherent delays which are long compared to the cycle time of the CPUs of the host and the client computers. Examples of commonly used high-latency data channels are telephone lines, wireless links such as cellular phone systems, and shared data networks such as the Internet. The inventors have observed that, regardless of the processing speeds of the CPUs of the two linked computers, the inherent delays in the data channel may result in unacceptably or uneconomically long synchronization times. It is not practical in many cases to avoid the use of high-latency data channels, since they are the most universally available data channels for most remote users of the handheld computers.
There is a need for an approach for speeding the record synchronization process, particularly in those cases where a high-latency data channel is used. The present invention fulfills this need, and further provides related advantages.
The present invention provides a software synchronization communication architecture that reduces the synchronization time of a host computer and a remote handheld client computer. The approach is generally applicable, although it is most beneficially applied when the host computer and the client computer communicate through a high-latency data channel. It may be utilized in conjunction with existing or future record synchronization techniques, and serves not to alter these record synchronization techniques but to operate in conjunction with them to speed the synchronization.
In accordance with the invention, a method for communicating synchronization information between at least one handheld client computer and a host computer comprises the steps of providing a host computer having a set of host databases (each comprising a set of data records) stored therein, providing a handheld client computer having a set of client databases stored therein and database/record change-indicators corresponding to those client databases/records which have been changed since the last prior synchronization, providing a data channel between the host computer and the handheld client computer (typically a high-latency data channel such as a telephone line, a wireless communications channel, or the Internet), establishing a data-link between the host computer and the handheld client computer through the data channel, and transferring from the handheld client computer to a cache in the host computer a skeletal snapshot of the client databases. The client database/record change-indicators may range from a simple flag indicating the occurrence and type of the change to a detailed time-stamp indicating the change type and the exact time of the change. The skeletal snapshot may include any information indicating the state of the remote databases and records, such as, for example, change-indicators and time-stamps, unique identifiers (e.g., database/record identification numbers), and/or database/record indices in an ordered list.
An up-transfer list of client records to be transferred from the client computer to the host computer is determined. The up-transfer list is determined by the communications architecture using the skeletal snapshot retrieved from the client computer and any a priori information known about the objectives and requirements of the synchronization to be performed. This a priori information may be estimated based upon typical synchronization rules or past synchronization history, but is not deterministically known. The detailed discussion of the preferred embodiment of the invention discusses examples of the skeletal information and the a priori knowledge used to determine the up-transfer list of client records. The records on the up-transfer list are up-transferred from the handheld client computer to the cache of the host computer and are associated with the skeletal snapshot, so as to be available to a record synchronization operation.
The method includes receiving from the record synchronization operation a set of updated and added host records to be down-transferred, as well as a set of requests to delete client records, wherein the step of up-transferring is initiated prior to an initiation of the step of receiving and down-transferring from the host computer to the handheld client computer the set of updated and added host records and the set of record deletion requests. The method further includes storing the updated and added host records in, and removing the deleted records from, the cache associated with the skeletal snapshot. The steps of up-transferring and down-transferring are accomplished in a full-duplex, asynchronous manner, thereby keeping the data channel as fully filled as possible.
The present approach establishes a skeletal snapshot of the client databases/records in a cache of the host computer, so that the host has ready access to this information for reference during synchronization. Based upon the skeletal snapshot of the client databases/records, it also identifies the client records of the handheld client that are to be up-transferred, and desirably immediately begins the up-transfer without waiting for further operations of the record synchronization. Thus, the up-transfer preferably proceeds without waiting for the record synchronization software to be fully loaded and ready for operation. The result is a shorter elapsed time for the up-transfer of the required client records, so that the client records are available in the host cache more quickly to permit the initiation and continuous functioning of the record synchronization.
The synchronized record output of the record synchronization function is stored in the host cache and also down-transferred to the handheld client computer, with the up-transfers and down-transfers proceeding in the full-duplex, asynchronous manner. The synchronized record output stored in the host cache is available for any further use by the host computer in the synchronization process. Absent this storage in the cache, the host may be required to up-transfer needed and previously synchronized records back from the client computer, wasting the bandwidth of the communications channel.
As the record synchronization proceeds, it is not uncommon that the record synchronization operation identifies additional client records that are required to accomplish the synchronization. Such additional client records are added to the up-transfer list as they are identified and up-transferred from the client computer to the host computer.
The use of the cache may be expanded by creating a virtual replica of the handheld computer within the cache of the host computer. To create the virtual client computer, the computer status and databases of the physical client computer are up-transferred to the cache of the host computer. The initial creation and population of the virtual client computer is time-consuming, but subsequent synchronization and modification of the virtual client computer are incremental and substantially faster. In addition to storing the handheld computer""s databases and status, the virtual client computer software may include routines for accessing and manipulating the stored data which mirror the operating system routines available on the handheld computer, and may, but not necessarily, include the operating system of the handheld computer. Having constructed and populated the virtual client computer, the synchronization operation may then be conducted in two stages. The first stage is a synchronization between the host databases and the virtual client computer. The second synchronization stage includes the up-transfer and down-transfer between the virtual client computer and the physical client computer when a physical connection is established, completing the synchronization of the client computer and the host computer. Such a two-stage synchronization may be preferable and more efficient in some cases, for example where the host computer databases are large and shared by numerous users and host computer access to the host databases is time-consuming. Breaking the synchronization into the two independent stages may reduce the time required for the physical client computer to be connected to the host computer relative to a one-stage synchronization where the client and host databases are synchronized directly without the use of a virtual device.
Once the virtual client computer is created in the cache, it may be stored in mass storage of the host computer, thereby serving as a backup of the entire physical client computer. The virtual client computer may also be down-transferred to the original client computer if it experiences a mechanical or electrical failure resulting in the inadvertent deletion of the client databases, or if there is a failure in the communications portion of the record synchronization operation. The virtual client computer may also be down-transferred from the host computer to another physical client computer, in the event that a duplicate client computer is required for any reason.
This approach is to be contrasted with the conventional software architecture and communication approach for synchronization. Conventional communications approaches operate in a half-duplex, synchronous manner. No effort is made by the communications software to determine lists of records to be up-transferred and down-transferred. No skeletal information is pre-fetched by the communications software prior to the execution of the synchronization program. No effort is made by the communications software to pre-fetch or cache records to be up-transferred or down-transferred. In conventional communications approaches, the communications module acts purely in response to requests from the synchronization program. Each request (e.g., to retrieve a record from the client computer, delete a record from the client computer, add a record to the client computer, etc.) is sent to the client computer, the response is retrieved from the client computer, and the communications software returns the response to the synchronization program. The synchronization program may not initiate a request until the previous request has been executed and a response returned. In the conventional approach, there is no integration and coordination between the synchronization program and the communications software, and there is no virtual device memory of the state and progress of the previous synchronization session.
The above-described communications methodology is accomplished with knowledge only of the client computer and its client databases/records, and without knowledge of the host records and the specific details of the record synchronization operation. The requirements of the synchronization operation are initially estimated based upon typical or past behavior. This situation is often encountered in practice, where the communications program is a software routine that does not receive this information from the synchronization software. Improved performance may be achieved by further integrating the communications methodology with the synchronization program. Significant performance improvement may be achieved with firm knowledge of the host computer""s database/record skeletal information and the synchronization rules to be applied to the data sets. This information could be requested by the communications logic at the onset of the synchronization session. Further improved performance can be achieved by integrating the communications logic and synchronization program into a single module. Full integration allows optimal creation of the initial up-transfer and down-transfer record lists and immediate modification of these lists as more information is determined during the synchronization process.
The present approach significantly reduces the record synchronization time in a host/client computer system, particularly where the two computers are linked by a high-latency data channel. Other features and advantages of the present invention will be apparent from the following more detailed description of the preferred embodiment, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the invention. The scope of the invention is not, however, limited to this preferred embodiment.